home *** CD-ROM | disk | FTP | other *** search
/ Info-Mac 4 / Info_Mac IV CD-ROM (Pacific HiTech Inc.)(August 1994).iso / Periodicals / CSMP / C.S.M.P. Digest, Issue 3.010 < prev    next >
Internet Message Format  |  1994-06-09  |  53KB

  1. From: pottier@clipper.ens.fr (Francois Pottier)
  2. Subject: csmp-digest-v3-010
  3. Date: Thu, 7 Apr 94 12:50:06 MET DST
  4.  
  5. C.S.M.P. Digest             Thu, 07 Apr 94       Volume 3 : Issue 10
  6.  
  7. Today's Topics:
  8.  
  9.         *Simple* CopyMask question
  10.         C-C++ public domain compiler
  11.         Code Fragment Loader and VM
  12.         Code to rebuild desktop?
  13.         CodeWarrior features?
  14.         Graphic Elements release announcement
  15.         How to get Finder icon?
  16.         Porting Think C to CodeWarrior
  17.         Quickdraw GX Beta 3 fun
  18.         Spoofing a serial port
  19.         Using Think Pascal Library in SC++
  20.         rowBytes for the screen too big?
  21.  
  22.  
  23.  
  24. The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
  25. (pottier@clipper.ens.fr).
  26.  
  27. The digest is a collection of article threads from the internet newsgroup
  28. comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
  29. regularly and want an archive of the discussions.  If you don't know what a
  30. newsgroup is, you probably don't have access to it.  Ask your systems
  31. administrator(s) for details.  If you don't have access to news, you may
  32. still be able to post messages to the group by using a mail server like
  33. anon.penet.fi (mail help@anon.penet.fi for more information).
  34.  
  35. Each issue of the digest contains one or more sets of articles (called
  36. threads), with each set corresponding to a 'discussion' of a particular
  37. subject.  The articles are not edited; all articles included in this digest
  38. are in their original posted form (as received by our news server at
  39. nef.ens.fr).  Article threads are not added to the digest until the last
  40. article added to the thread is at least two weeks old (this is to ensure that
  41. the thread is dead before adding it to the digest).  Article threads that
  42. consist of only one message are generally not included in the digest.
  43.  
  44. The digest is officially distributed by two means, by email and ftp.
  45.  
  46. If you want to receive the digest by mail, send email to listserv@ens.fr
  47. with no subject and one of the following commands as body:
  48.     help                        Sends you a summary of commands
  49.     subscribe csmp-digest Your Name    Adds you to the mailing list
  50.     signoff csmp-digest            Removes you from the list
  51. Once you have subscribed, you will automatically receive each new
  52. issue as it is created.
  53.  
  54. The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
  55. Questions related to the ftp site should be directed to
  56. scott.silver@dartmouth.edu. Currently no previous volumes of the CSMP
  57. digest are available there.
  58.  
  59. Also, the digests are available to WAIS users as comp.sys.mac.programmer.src.
  60.  
  61.  
  62. -------------------------------------------------------
  63.  
  64. >From gk1@acpub.duke.edu (Gavin  Kistner)
  65. Subject: *Simple* CopyMask question
  66. Date: 21 Mar 1994 21:07:59 GMT
  67. Organization: Duke University; Durham, NC; USA
  68.  
  69.  
  70. I'm new to programming the mac (making my first) and want to use CopyMask
  71. to put a picture over a background with a non-square clip.
  72. The picture is stored as a 'PICT' resource, but CopyMask needs a BitMap
  73. (or pixMap for source or dest) record.  The placement is a one-shot
  74. deal...I've been trying to understand some serious SPRITE toolkits, but
  75. they're way too overkill and (I think) complex.
  76.  
  77. Can someone give me the simplest, even ineffecient, way to use CopyMask
  78. with 'PICT' resources.  I'm programming in C, if you want to show in
  79. source code :D
  80. Oh, and there are actually many pieces and masks to use...I can either
  81. keep them in one conglomerate picture or put each in its own
  82. resource...you tell me.
  83.  
  84. One other question - I've used Photoshop to create beautifully dithered
  85. 8-bit versions from the 24-bit originals, but when I tell PS to save the
  86. colormap it created, it makes some file that's all data fork...I want a
  87. 'clut' to set the palette up correctly, right?  Anyone know of an easy way
  88. to do this?  Or even a hard one?
  89.  
  90. Many thanks, and may God bless the Mac and especially its programmers!
  91.  
  92. - Gavin
  93.  
  94. PS My apologies if this appeared before...I tried to post it last night, but
  95. never was able to find my article.  Perhaps my newsreader is messed -
  96. perhaps it would be best if you could mail replies to me directly.
  97. gk1@acpub.duke.edu
  98. -- 
  99. This message brought to you by Gavin Kistner, aka The Rabid Yak, aka RabYak
  100. gk1@acpub.duke.edu   My experimental ftp server: alspaugh-2181.dorm.duke.edu
  101.  
  102. +++++++++++++++++++++++++++
  103.  
  104. >From Arsenault_C@msm.cdx.mot.com (Chris Arsenault)
  105. Date: Thu, 24 Mar 1994 12:26:29 -0500
  106. Organization: Motorola Codex
  107.  
  108. In article <2ml2bf$76l@news.duke.edu>, gk1@acpub.duke.edu (Gavin  Kistner)
  109. wrote:
  110.  
  111. > Can someone give me the simplest, even ineffecient, way to use CopyMask
  112. > with 'PICT' resources?
  113.  
  114. I'm assuming here that your 'PICT's are primarily pixel or paint images vs
  115. drawn (pict opcode) images. 
  116.  
  117. Grab a copy of Tony Myle's excellent SpriteWorld sprite library on
  118. sumex-aim or some of the other ftp archives.  There are a number of image
  119. functions provided in the utilities file that allow you to load pictures
  120. into GWorlds etc. This is a good starting point for what I describe below.
  121.  
  122. Draw your pict image in a paint program. Duplicate the file and convert it
  123. to a 1 bit (B&W) image. This is your mask bitmap.  Copy this into your
  124. resource file. Load the mask bitmap into a grafport (there is a function in
  125. the SpriteWorld utils that does this), then use this for your CopyMask
  126. operation, or alternately convert the bitmap mask into a region
  127. (BitmapToRegion) and use CopyBits with the maskRgn. 
  128.  
  129. There are a number of other ways to mask off images, but this should get
  130. you started.
  131.  
  132. > One other question - I've used Photoshop to create beautifully dithered
  133. > 8-bit versions from the 24-bit originals, but when I tell PS to save the
  134. > colormap it created, it makes some file that's all data fork...I want a
  135. > 'clut' to set the palette up correctly, right?  Anyone know of an easy way
  136. > to do this?  Or even a hard one?
  137.  
  138. There is a problem with how color information is exchanged when working
  139. with various paint programs. (Images that are copied into a ResEdit PICT do
  140. not retain the correct palette that the paint program uses, but use the
  141. system palette instead)  I'll assume that you are using PS to save the
  142. image as a PICT resource so you should be okay. Do a GetPicture to obtain
  143. the PicHandle, then use the Picture Utilities call GetPictInfo().  This
  144. will return all the information you could need about the picture, including
  145. a CTabHandle (the color table for the picture). The GetPictInfo also
  146. returns a palette. If you assign this palette to the window you're going to
  147. display your picture in, you'll get the correct picture colors in the
  148. window instead of the approximations the Palette Manager provides.
  149.  
  150. Have fun!
  151.  Chris
  152. -- 
  153. #include <UsualLegalDisclaimers.h>
  154.  
  155. ---------------------------
  156.  
  157. >From giac@ada.dei.unipd.it (Giovanni Iachello 366675/IF)
  158. Subject: C-C++ public domain compiler
  159. Date: Mon, 14 Mar 1994 11:55:05 GMT
  160. Organization: B.B.B - Universita' di Padova, Italia
  161.  
  162. does anybody know where to find a public domain C/C++ compiler for the
  163. MAc? Maybe the GNU compiler?
  164.  
  165. Thank you!
  166. giac@maya.dei.unipd.it
  167.  
  168.  
  169. +++++++++++++++++++++++++++
  170.  
  171. >From arentz@batcave.knoware.nl (Stefan Arentz)
  172. Date: Sun, 20 Mar 1994 13:04:42 GMT
  173. Organization: Knoware
  174.  
  175. In article <CMnL3v.95q@dei.unipd.it>, giac@ada.dei.unipd.it (Giovanni
  176. Iachello 366675/IF) wrote:
  177.  
  178. > does anybody know where to find a public domain C/C++ compiler for the
  179. > MAc? Maybe the GNU compiler?
  180. > Thank you!
  181. > giac@maya.dei.unipd.it
  182.  
  183. On the MacHack '93 CD, there is a GNU 2.3.3 C and C++ compiler. You need
  184. MPW to use it though...
  185.  
  186. -- Stefan
  187.  
  188. - -----------------------------------------------------------------------
  189. Stefan Arentz          -- Software Constructor --       arentz@knoware.nl
  190.  
  191. +++++++++++++++++++++++++++
  192.  
  193. >From holiday@bnr.ca (Matthew Holiday)
  194. Date: 21 Mar 1994 15:20:47 GMT
  195. Organization: Bell-Northern Research, Richardson, TX
  196.  
  197. In article <arentz-200394150442@batcave.knoware.nl>, arentz@batcave.knoware.nl (Stefan Arentz) writes:
  198. -> In article <CMnL3v.95q@dei.unipd.it>, giac@ada.dei.unipd.it (Giovanni
  199. -> Iachello 366675/IF) wrote:
  200. -> 
  201. -> > does anybody know where to find a public domain C/C++ compiler for the
  202. -> > MAc? Maybe the GNU compiler?
  203. -> > 
  204. -> > Thank you!
  205. -> > giac@maya.dei.unipd.it
  206. -> 
  207. -> On the MacHack '93 CD, there is a GNU 2.3.3 C and C++ compiler. You need
  208. -> MPW to use it though...
  209.  
  210. Where can one obtain this CD?  And how much does it cost?
  211.  
  212. -- 
  213. Matt Holiday                                  #include <std/disclaimer>
  214. holiday@bnr.ca
  215. BNR Richardson, TX            "Proud owner of an unregistered computer"
  216.  
  217. +++++++++++++++++++++++++++
  218.  
  219. >From shebs@cygnus.com (Stan Shebs)
  220. Date: Mon, 21 Mar 1994 18:26:24 GMT
  221. Organization: /cygint/s1/users/shebs/.organization
  222.  
  223.  
  224. In article <2mke0f$cqr@crchh327.bnr.ca> holiday@bnr.ca (Matthew Holiday) writes:
  225.  
  226.    -> On the MacHack '93 CD, there is a GNU 2.3.3 C and C++ compiler. You need
  227.    -> MPW to use it though...
  228.  
  229.    Where can one obtain this CD?  And how much does it cost?
  230.  
  231. There is also a slightly more up-to-date version of 2.3.3 on
  232. ftp.atg.apple.com.  Neither version is totally usable however,
  233. since they have some bugs in code generation for Pascal-declared
  234. functions.  With care, you might be able to use it, but don't cry
  235. too loudly if the object code crashes and takes your machine with it.
  236.  
  237. At this point, I've abandoned the 2.3.3 port and am starting over with
  238. a different strategy for 2.5.x, involving very few MPW-Assembler-specific
  239. hacks and a *real* cross-compilation setup (i.e. sit on a Sun and produce
  240. a Mac executable, resources, fat binary, etc as desired).
  241.  
  242.                             Stan Shebs
  243.                             Cygnus Support
  244.                             shebs@cygnus.com
  245.  
  246. +++++++++++++++++++++++++++
  247.  
  248. >From holiday@bnr.ca (Matthew Holiday)
  249. Date: 22 Mar 1994 14:47:05 GMT
  250. Organization: Bell-Northern Research, Richardson, TX
  251.  
  252. In article <SHEBS.94Mar21102624@andros.cygnus.com>, shebs@cygnus.com (Stan Shebs) writes:
  253. -> 
  254. -> In article <2mke0f$cqr@crchh327.bnr.ca> holiday@bnr.ca (Matthew Holiday) writes:
  255. -> 
  256. ->    -> On the MacHack '93 CD, there is a GNU 2.3.3 C and C++ compiler. You need
  257. ->    -> MPW to use it though...
  258. -> 
  259. ->    Where can one obtain this CD?  And how much does it cost?
  260. -> 
  261. -> There is also a slightly more up-to-date version of 2.3.3 on
  262. -> ftp.atg.apple.com.  Neither version is totally usable however,
  263. -> since they have some bugs in code generation for Pascal-declared
  264. -> functions.  With care, you might be able to use it, but don't cry
  265. -> too loudly if the object code crashes and takes your machine with it.
  266. -> 
  267. -> At this point, I've abandoned the 2.3.3 port and am starting over with
  268. -> a different strategy for 2.5.x, involving very few MPW-Assembler-specific
  269. -> hacks and a *real* cross-compilation setup (i.e. sit on a Sun and produce
  270. -> a Mac executable, resources, fat binary, etc as desired).
  271.  
  272. That's neat, but all I want to do is compile MPW tools under MPW, using C++
  273. instead of C.
  274.  
  275. Thanks for 2.3.3 -- I'm going to try building that tonight.  Does the C++
  276. front end part of 2.3.3 work, or am I stuck with Apple's port of CFront 2.1?
  277.  
  278. -- 
  279. Matt Holiday                                  #include <std/disclaimer>
  280. holiday@bnr.ca
  281. BNR Richardson, TX            "Proud owner of an unregistered computer"
  282.  
  283. +++++++++++++++++++++++++++
  284.  
  285. >From shebs@cygnus.com (Stan Shebs)
  286. Date: Tue, 22 Mar 1994 21:57:02 GMT
  287. Organization: /cygint/s1/users/shebs/.organization
  288.  
  289. In article <2mn0d9$8k3@crchh327.bnr.ca> holiday@bnr.ca (Matthew Holiday) writes:
  290.  
  291.    That's neat, but all I want to do is compile MPW tools under MPW, using C++
  292.    instead of C.
  293.  
  294.    Thanks for 2.3.3 -- I'm going to try building that tonight.  Does the C++
  295.    front end part of 2.3.3 work, or am I stuck with Apple's port of CFront 2.1?
  296.  
  297. Although I haven't tried it lately, "cc1plus" has been observed to build
  298. and run under MPW.  However, it won't generate code that will link with any
  299. MPW C++ libraries (different name mangling).  You would have to recompile
  300. any and all libraries from source code, then work out a way to run static
  301. constructors and destructors, and do many other weird and obscure bits of
  302. work.  Might take a couple weeks of dinking around.  Note also that the
  303. dialect of C++ is different than what you would get with CFront 2.1, or
  304. even the latest (2.5.8) version of GCC.
  305.  
  306.                             Stan Shebs
  307.                             Cygnus Support
  308.                             shebs@cygnus.com
  309.  
  310.  
  311. +++++++++++++++++++++++++++
  312.  
  313. >From holiday@bnr.ca (Matthew Holiday)
  314. Date: 23 Mar 1994 20:48:57 GMT
  315. Organization: Bell-Northern Research, Richardson, TX
  316.  
  317. In article <SHEBS.94Mar22135702@andros.cygnus.com>, shebs@cygnus.com (Stan Shebs) writes:
  318. -> In article <2mn0d9$8k3@crchh327.bnr.ca> holiday@bnr.ca (Matthew Holiday) writes:
  319. -> 
  320. ->    That's neat, but all I want to do is compile MPW tools under MPW, using C++
  321. ->    instead of C.
  322. -> 
  323. ->    Thanks for 2.3.3 -- I'm going to try building that tonight.  Does the C++
  324. ->    front end part of 2.3.3 work, or am I stuck with Apple's port of CFront 2.1?
  325. -> 
  326. -> Although I haven't tried it lately, "cc1plus" has been observed to build
  327. -> and run under MPW.  However, it won't generate code that will link with any
  328. -> MPW C++ libraries (different name mangling).  You would have to recompile
  329. -> any and all libraries from source code, then work out a way to run static
  330. -> constructors and destructors, and do many other weird and obscure bits of
  331. -> work.  Might take a couple weeks of dinking around.  Note also that the
  332. -> dialect of C++ is different than what you would get with CFront 2.1, or
  333. -> even the latest (2.5.8) version of GCC.
  334.  
  335. Good points.  I really hadn't thought about name mangling conventions.  It's
  336. probably more effort than I've got to put into it to make it work with MPW.
  337.  
  338. I haven't heard anything from Apple/APDA about planned improvements to MPW
  339. C++ (i.e., supporting a later version of the C++ language), so I guess I'll
  340. just keep doing tools in C.  Or switch to a Unix machine....
  341.  
  342. -- 
  343. Matt Holiday                                  #include <std/disclaimer>
  344. holiday@bnr.ca
  345. BNR Richardson, TX            "Proud owner of an unregistered computer"
  346.  
  347. ---------------------------
  348.  
  349. >From Willie Rauchwerger <willie-rauchwerger@uokhsc.edu>
  350. Subject: Code Fragment Loader and VM
  351. Date: 17 Mar 1994 19:53:35 GMT
  352. Organization: OU Health Sciences Center
  353.  
  354. Here is a dumb question...
  355.  
  356. Why does your application memory requirement decrease on native PPC
  357. apps when virtual memory is turned on?
  358.  
  359. - -----------------------------------------------------------------
  360. Willie Rauchwerger         AppleLink: Willie
  361. Telemedicine Software Guy  Internet:  willie-rauchwerger@uokhsc.edu
  362. OU Health Sciences Center
  363.  
  364. +++++++++++++++++++++++++++
  365.  
  366. >From rang@winternet.mpls.mn.us (Anton Rang)
  367. Date: 19 Mar 1994 02:01:14 GMT
  368. Organization: Minnesota Angsters
  369.  
  370. In article <2macfv$7iv@romulus.ucs.uoknor.edu> Willie Rauchwerger <willie-rauchwerger@uokhsc.edu> writes:
  371. >Here is a dumb question...
  372.  
  373.   Actually, it's not a dumb question.  :-)
  374.  
  375. >Why does your application memory requirement decrease on native PPC
  376. >apps when virtual memory is turned on?
  377.  
  378.   When virtual memory is turned on, an application's code (as well as
  379. that of any shared libraries it uses) is mapped into high memory,
  380. rather than being loaded into the application heap.  Because this
  381. high-memory area doesn't correspond to real RAM, the program doesn't
  382. need any memory to be allocated for its code.
  383. --
  384. Anton Rang (rang@winternet.mpls.mn.us)
  385.  
  386. +++++++++++++++++++++++++++
  387.  
  388. >From peirce@outpost.SF-Bay.org (Michael Peirce)
  389. Date: Wed, 23 Mar 94 21:09:25 PST
  390. Organization: Peirce Software, Inc.
  391.  
  392.  
  393. In article <2macfv$7iv@romulus.ucs.uoknor.edu> (comp.sys.mac.programmer), Willie Rauchwerger <willie-rauchwerger@uokhsc.edu> writes:
  394. > Here is a dumb question...
  395. > Why does your application memory requirement decrease on native PPC
  396. > apps when virtual memory is turned on?
  397.  
  398. No CODE resources get loaded into your heap.  With VM turned on, your
  399. code (from the data fork) is paged into its own memory area as needed
  400. (and it never gets paged back to disk since it's read only, it can
  401. always be read back from the data fork).
  402.  
  403.  
  404. -- Michael Peirce        -- peirce@outpost.sf-bay.org
  405. -- Peirce Software, Inc. -- 719 Hibiscus Place, Suite 301
  406. --                       -- San Jose, California USA 95117
  407. -- Makers of: Smoothie & -- voice: +1.408.244.6554 fax: +1.408.244.6882
  408. --    Peirce Print Tools -- AppleLink: peirce & America Online: AFC Peirce
  409.  
  410. ---------------------------
  411.  
  412. >From martinher@urvax.urich.edu
  413. Subject: Code to rebuild desktop?
  414. Date: Tue, 22 Mar 1994 18:46:44 GMT
  415. Organization: University of Richmond
  416.  
  417. Does anyone have a pointer to source code (C/C++ preferred) to rebuild
  418. the desktop?
  419.  
  420. Herb Martin 
  421. martinher@urvax.urich.edu
  422.  
  423. +++++++++++++++++++++++++++
  424.  
  425. >From leonardr@netcom.com (Leonard Rosenthol)
  426. Date: Thu, 24 Mar 1994 18:53:07 GMT
  427. Organization: Aladdin Systems, Inc.
  428.  
  429. In article <1994Mar22.184329.22097@gossip.urich.edu>,
  430. martinher@urvax.urich.edu wrote:
  431.  
  432. > Does anyone have a pointer to source code (C/C++ preferred) to rebuild
  433. > the desktop?
  434. >  
  435.    It is IMPOSSIBLE for an application to do the rebuild itself since most
  436. of the contents of the Desktop File are undocumented. 
  437.  
  438.    What you can do is to ask the Finder to quit (via Apple events), delete
  439. the DTDB files yourself, and the relaunch the Finder.  At that point the
  440. Finder will rebuild the DTDB for you.
  441.  
  442. Leonard
  443. - ------------------------------------------------------------------------
  444. Leonard Rosenthol                      Internet:       leonardr@netcom.com
  445. Director of Advanced Technology        AppleLink:      MACgician
  446. Aladdin Systems, Inc.                  GEnie:          MACgician
  447.  
  448. ---------------------------
  449.  
  450. >From mdiamond@gradient.cis.upenn.edu (Matthew T Diamond)
  451. Subject: CodeWarrior features?
  452. Date: 23 Mar 1994 19:56:35 GMT
  453. Organization: University of Pennsylvania
  454.  
  455.  
  456. I know; every coupla days someone wants to know if
  457. CodeWarrior supports feature X.
  458.  
  459. But I AM very curious about it.  Is there any online
  460. information available that summarizes the whole thing?
  461. I would like to learn more about the editing environment,
  462. as well as what tools it comes with, how good is the code,
  463. what debugging is like, etc.  (Yes, I know it's still alpha or beta)
  464.  
  465. Presumably some kind of promotional text was written up
  466. somewhere?  It might answer my own and other folks' questions.
  467.  
  468. Matt
  469. mdiamond@gradient.cis.upenn.edu
  470.  
  471. ps. On a related note, I noticed that Symantec 7.0 press releases
  472. didn't mention improvements to the editor.  Did I miss something??
  473.  
  474. +++++++++++++++++++++++++++
  475.  
  476. >From mwron@aol.com (MW Ron)
  477. Date: 23 Mar 1994 17:15:03 -0500
  478. Organization: America Online, Inc. (1-800-827-6364)
  479.  
  480. In article <2mq6tj$abe@netnews.upenn.edu>, mdiamond@gradient.cis.upenn.edu
  481. (Matthew T Diamond) writes:
  482. >Is there any online information available that summarizes the whole thing?
  483.  
  484.  
  485. a bit of background on Metrowerks:
  486.  
  487. Metrowerks has been developing and selling  academic computer language
  488. products since 1988 and has registered users in 26 countries.
  489.  
  490. On January 5th, 1994, Metrowerks introduced Metrowerks CodeWarrior, a
  491. completely new, very powerful development environment for C/C++ and Pascal on
  492. either 68K Macintosh or the new PowerMacintosh.
  493.  
  494. Metrowerks CodeWarrior contains very fast, state-of-the-art compiler
  495. technology that builds your products faster than any other development
  496. environment on Macintosh. CodeWarrior also is compatible with MPW C/C++
  497. source code and both MacApp 3.1 and the TCL have been successfully compiled
  498. with CodeWarrior since introduction. It is currently in use in most of the
  499. major software companies worldwide to port their products to the new
  500. PowerMacintosh.
  501.  
  502. Also included on the CodeWarrior CD is PowerPlant, our new application
  503. framework, written by Greg Dow, the orginal architect of the Think Class
  504. Library.
  505.  
  506.  
  507. Metrowerks business hours are (EST):
  508.  
  509. Monday to Friday, 9 AM to 5 PM.
  510.  
  511. Address:
  512.  
  513. In the USA
  514. Metrowerks, Inc
  515. The Trimex Building
  516. Route 11, Mooers NY
  517. 12958
  518.  
  519. Canada and International
  520. Metrowerks, Inc
  521. 1500 Du College, Suite 300
  522. St-Laurent, QC
  523. H4L 5G6
  524.  
  525. Other electronic addresses:
  526.  
  527. support@metrowerks.ca
  528. sales@metrowerks.ca
  529. MWRON@AOL.COM
  530.  
  531. Tel:  (514) 747-5999
  532. Fax:  (514) 747-2822
  533.  
  534.  
  535.  
  536.  
  537. +++++++++++++++++++++++++++
  538.  
  539. >From jwbaxter@olympus.net (John W. Baxter)
  540. Date: Thu, 24 Mar 1994 15:10:58 -0800
  541. Organization: Internet for the Olympic Peninsula
  542.  
  543. In article <2mq6tj$abe@netnews.upenn.edu>, mdiamond@gradient.cis.upenn.edu
  544. (Matthew T Diamond) wrote:
  545.  
  546. > I know; every coupla days someone wants to know if
  547. > CodeWarrior supports feature X.
  548. > But I AM very curious about it.  Is there any online
  549. > information available that summarizes the whole thing?
  550. > I would like to learn more about the editing environment,
  551. > as well as what tools it comes with, how good is the code,
  552. > what debugging is like, etc.  (Yes, I know it's still alpha or beta)
  553.  
  554. MacTech magazine has had several articles recently about CodeWarrior. 
  555. *Should* be available at your library, but with budgets the way they are
  556. these days, who knows.  [MacTech is also a convenient place to buy
  557. CodeWarrior.  That does not seem (to this outsider) to have affected the
  558. articles.]
  559.  
  560. Frameworks magazine has, I think, had one or two, also.  Harder to find.
  561.  
  562. Both "MacTech" and "develop" are essential parts of one's Macintosh
  563. developer closet, IMHO.
  564. -- 
  565. John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
  566.    jwbaxter@pt.olympus.net
  567.  
  568. ---------------------------
  569.  
  570. >From al@crucible.powertools.com (Al Evans)
  571. Subject: Graphic Elements release announcement
  572. Date: 23 Mar 94 15:41:54 GMT
  573. Organization: PowerTools, Austin, Texas
  574.  
  575.  
  576. I am pleased to announce the net release of Graphic Elements. 
  577. Graphic Elements is a new paradigm for implementing high-performance
  578. interactive computer graphics in a framework-independent (and, 
  579. potentially, platform-independent) manner. The Graphic Elements 
  580. system is modular and extensible, and individual Graphic Elements
  581. can be re-used in new applications by simple inclusion.
  582.  
  583. This release is available from mac.archive.umich.edu and its mirrors 
  584. in the file:
  585.  
  586.     /mac/misc/demo/graphicelementsdemo.sit.hqx
  587.  
  588. I do not know why they put it in the demo area, since it is a 
  589. completely functional version including linkable library and
  590. examples with source code (Think C 6.0). Note: I do ask a
  591. fee for the "registered shareware version", which includes
  592. an additional code module to speed up the graphics, a linkable
  593. MPW library, source for a TCL pane, and source for a MacApp view.
  594.  
  595. Here are some excerpts from the Graphic Elements README file:
  596.  
  597. [begin excerpts]
  598.  
  599. Graphic Elements is a very general, high-performance, framework-
  600. independent graphics presentation system. It offers graphic performance 
  601. comparable to that of a "sprite animation" system. At the same time, it 
  602. affords a very flexible mechanism for defining what a graphic is and does. 
  603. Anything that can be drawn on the screen can be a Graphic Element.
  604.  
  605. ...the Graphic Elements system is completely "legal". Any normal 
  606. Macintosh window can contain a Graphic Elements "world".
  607.  
  608. >From the viewpoint of the application programmer, a Graphic Element is
  609. an independent software object which knows how to image itself on
  610. demand into an offscreen workspace. Each Graphic Element may optionally
  611. have ways of reacting to 1) the passage of time, 2) contact with
  612. another Graphic Element, and 3) the user's actions. These methods will
  613. be called automatically by the Graphic Elements system, as required. In
  614. addition, the application program can act on Graphic Elements explicitly
  615. at any time.
  616.  
  617. After initialization, the application (or the view or pane object, if 
  618. a class library is being used) needs only two calls to the Graphic 
  619. Elements system to run a window full of animated graphics.
  620.  
  621. ...the Graphic Elements system allows any graphic to be defined as a 
  622. Graphic Element.
  623.  
  624. ...scenes can easily be moved from one program to another by simply 
  625. including them in the new program and calling their initialization 
  626. routines.
  627.  
  628. The same Graphic Elements "scene" source can [...] be compiled under 
  629. MPW C or C++, Think C 6.0, and Symantec C++. The compiled code can be 
  630. utilized from a normal application or from one based on the MacApp 
  631. or TCL class libraries.
  632.  
  633. [end excerpts]
  634.  
  635. If you're still with me, thank you for your attention.
  636.  
  637.                     --Al Evans--
  638. -- 
  639.  
  640. Al Evans                         Tu causes, tu causes
  641. al@crucible.powertools.com               C'est tout ce que tu sais faire
  642. cs.utexas.edu!crucible!al                     -- LaVerdure
  643.  
  644. ---------------------------
  645.  
  646. >From Steve Barrera <barrera@vt.edu>
  647. Subject: How to get Finder icon?
  648. Date: 23 Mar 1994 16:37:33 GMT
  649. Organization: Computing Center
  650.  
  651.  
  652. I want to make a call to the standard get file dialog, then extract 
  653. the Finder icon associated with the selected file and put it in a window.
  654. I can't find a hint anywhere in Inside Mac:Files as to how to do this.
  655. Anyone have a clue?
  656.  
  657. Steve Barrera
  658. barrera@vt.edu
  659.  
  660. +++++++++++++++++++++++++++
  661.  
  662. >From E.J. Draper <utmdacc@odin.mda.uth.tmc.edu>
  663. Date: 23 Mar 1994 17:06:04 GMT
  664. Organization: U.T.M.D. Anderson Cancer Center
  665.  
  666. In article <2mpr8d$9nr@solaris.cc.vt.edu> Steve Barrera, barrera@vt.edu
  667. writes:
  668. >I can't find a hint anywhere in Inside Mac:Files as to how to do this.
  669. >Anyone have a clue?
  670.  
  671.  
  672. Here!s a little snippet.  The main call you!re looking for is
  673. PBDTGetIcon().  
  674.  
  675. PBDTGetIcon() is only available on volumes that use the System 7 desktop
  676. manager scheme.
  677.  
  678.  
  679.  
  680.  
  681.     clearbytes(&DTDBparamBlock,longsizeof(DTDBparamBlock));
  682.  
  683.     DTDBparamBlock.ioVRefNum = volrefnum;
  684.  
  685.     DTDBparamBlock.ioNamePtr = nil;
  686.  
  687.     if (PBDTGetPath(&DTDBparamBlock) == noErr)
  688.     {
  689.         if (DTDBparamBlock.ioDTRefNum == 0)
  690.         {
  691.             return nil;
  692.         }
  693.         
  694.         icondata = NewPtrClear(kLarge8BitIconSize);
  695.         
  696.         if (icondata == nil)
  697.             {
  698.                 return nil;
  699.             }
  700.             
  701.         DTDBparamBlock.ioDTReqCount = kLarge8BitIconSize;
  702.         
  703.         DTDBparamBlock.ioDTBuffer = icondata;
  704.         
  705.         DTDBparamBlock.ioIconType = kLarge8BitIcon;
  706.         
  707.         DTDBparamBlock.ioFileCreator = Creator;
  708.         
  709.         DTDBparamBlock.ioFileType = Type;
  710.         
  711.         Err = PBDTGetIcon(&DTDBparamBlock,false);
  712.         
  713.         if (Err == afpItemNotFound)
  714.             {
  715.                 DisposePtr(icondata);
  716.                 
  717.                 icondata = nil;
  718.  
  719.                 thePic = dogenericdocicon();
  720.                 
  721.                 if (thePic != nil)
  722.                 {
  723.                     return thePic;
  724.                 }
  725.                 
  726.                 return nil;
  727.             }
  728.  
  729.  
  730.       |E|J-  ED DRAPER
  731.  rEpar|D|<-  Radiologic/Pathologic Institute
  732.              The University of Texas M.D. Anderson Cancer Center
  733.              draper@utmdacc.mda.uth.tmc.edu
  734.  
  735. ---------------------------
  736.  
  737. >From tchan@irus.rri.uwo.ca (Thomas KC Chan)
  738. Subject: Porting Think C to CodeWarrior
  739. Date: 22 Mar 1994 21:57:21 GMT
  740. Organization: Imaging Labs, Robarts Research Institute, London
  741.  
  742.  
  743. I am porting my programs from Think C to CodeWarrior.  Right now I
  744. am just testing the 68K port.  The programs works...but...
  745.  
  746.    1. when I time my program speed using clock(), the program gives
  747.       me a big ellapse time.  It turns out that the constant CLOCKS_PER_SEC
  748.       is declared as (_CPS which is) 1.  I check with Think C and find 
  749.       that it has CLOCKS_PER_SEC declared as 60.  ???
  750.  
  751.    2. My program generates output for a line counter using ANSI printf.
  752.       Everything I use "\r" to overwrite the previous value. It works
  753.       in Think C.  But in CodeWarrior, the output would go to SIOUX. And
  754.       seemingly the "\r" character is treated as a new-line char.  ???
  755.  
  756.  
  757. Any one knows any fix to my problems?  Are patches needed for my
  758. CodeWarrior (Gold) compiler?  
  759.  
  760. I find the on-line ref. manual does not provide enough details 
  761. (like PowerPC's PEF [what is it anyways???]) Is there any doc 
  762. available on s/w porting to PowerPC?
  763.  
  764.  
  765.  
  766. Thomas Chan                   email: tchan@irus.rri.uwo.ca
  767.  
  768. +++++++++++++++++++++++++++
  769.  
  770. >From mlevy@csr.uvic.ca (Michael Levy)
  771. Date: Wed, 23 Mar 94 13:38:46 GMT
  772. Organization: University of Victoria
  773.  
  774. In Article <2mnpk1$8ol@falcon.ccs.uwo.ca>, tchan@irus.rri.uwo.ca (Thomas KC
  775. Chan) wrote:
  776. >
  777. >I am porting my programs from Think C to CodeWarrior.  Right now I
  778. >am just testing the 68K port.  The programs works...but...
  779. >
  780. >   1. when I time my program speed using clock(), the program gives
  781. >      me a big ellapse time.  It turns out that the constant CLOCKS_PER_SEC
  782. >      is declared as (_CPS which is) 1.  I check with Think C and find 
  783. >      that it has CLOCKS_PER_SEC declared as 60.  ???
  784.  
  785. Yes, I found this too. Change #define _CPS 1 to #define _CPS 60
  786. in <yval.h>. (See item 2 in the bug-report below).
  787.  
  788. There were a couple of other bugs that I have reported to Metrowerks.
  789. There was no response from them, but I assume they
  790. will fix most of them in the next release. The most serious bug 
  791. (not included in the report) was with malloc - its supposed to take
  792. an unsigned long as its argument. Instead, it is treating its argument
  793. as a signed int. If you try to allocated more than 32,767 bytes, malloc
  794. will return NULL. (Actually, its a bit worse than this. It is taking the
  795. least significant 16 bits of its argument, and treating that as a signed
  796. int. If you pass a long that is larger than 32,767, but which happens to
  797. have a zero in bit 16, malloc will succeed, giving you much less storage
  798. than you think you received). I did phone tech-support about this bug,
  799. and they said that it would be fixed in their next releasw
  800. (apparantly being cut into CD as we spoke - about 2 or 3 weeks ago).
  801.  
  802. I do not know about your second problem, but here for your benefit,
  803. and for the benefit of anyone else trying a THINK C->Metroworks C port,
  804. is a copy of the message I sent them. Because of these problems
  805. (and, most notably, with the debuggers inability to evaluate
  806. expressions,) SYMANTEC still gets my vote as the ANSI C compiler
  807. of choice for the Mac. I haven't done any C++ programming on the
  808. Mac, so I am not entering the other debate.
  809.  
  810. Here is the bug report:
  811.  
  812. 1. In the <yval.h> file, you have
  813. #define _ILONG 1
  814. Shouldn't this be conditional, depending on the value
  815. of __FOURBYTEINTS__?
  816.  
  817. 2. In the same file,
  818. #define _CPS 1
  819. is wrong - shouldn't it be 60 on the Mac? I think its
  820. ticks-per-second to divide into the value returned
  821. by the ANSI function clock().
  822.  
  823. 3. SystemSevenOrLater seems to be defined as 0 instead of 1
  824. even though I am using system 7.1. I can't figure out how to change
  825. it, or find out where it is defined.
  826.  
  827. 4. I got the version 1.a -> 1.b updater. It changed Macheaders
  828. but not Macheaders.c What gives?
  829.  
  830. 5. The predefined names in the C manual (such as __mwerks__)
  831. are in lower-case. They should be in upper case.
  832.  
  833.  
  834. I also noticed some bugs in the debugger, most notably,
  835. in a case like this:
  836.  
  837. int t1,t2;
  838. ....
  839. t1 = 1000;
  840. t2 = 2000;
  841. ...
  842. the debugger showed the same values for t1 and t2, and
  843. changed them simultaneously!
  844.  
  845. While I am on the debugger, I would like to add an item
  846. to your wishlist. I like the overall structure of your debugger
  847. when compared with THINK C. However, for me it is crucial
  848. to be able to evaluate expressions in the debugger. For example,
  849. I have a horrible macro called TAG(X) defined like this:
  850. #define TAG(X) \
  851. ((!(heap[X]&1))?(heap[X]&3):((!(heap[X]&2))?(heap[X]&15):(heap[X]&63)))
  852.  
  853. THINK C's debugger lets me place the expression TAG(X) in the "data"
  854. window and see a value (like 1 or 63). I find this soooo useful.
  855. Please consider adding something similar. In fact, if I could
  856. coerce the result to an enum type and get the symbol instead of
  857. a number in the debugger, I would be ecstatic.
  858.  
  859. Good luck with your product.
  860.  
  861. +============================================+
  862. | Michael Levy                               |
  863. | Department of Computer Science             |
  864. | University of Victoria                     |
  865. | PO Box 3055 Victoria B.C.                  |
  866. | Canada V8W 3P6                             |
  867. | email: mlevy@csr.uvic.ca                   |
  868. | phone: (604) 721-7303                      |
  869. | fax: (604) 721-7292                        |  
  870. +============================================+
  871.  
  872. +++++++++++++++++++++++++++
  873.  
  874. >From johnmce@world.std.com (John McEnerney)
  875. Date: Thu, 24 Mar 1994 02:18:33 GMT
  876. Organization: The World Public Access UNIX, Brookline, MA
  877.  
  878. >int t1,t2;
  879. >....
  880. >t1 = 1000;
  881. >t2 = 2000;
  882. >...
  883. >the debugger showed the same values for t1 and t2, and
  884. >changed them simultaneously!
  885.  
  886. This is probably -not- a bug in the debugger. If the compiler can 
  887. determine that t1 and t2 will never be live simultaneously, it is free to 
  888. place them in the same register or memory location. In fact, it is free 
  889. to delete the assignments altogether if t1 and t2 are never used. (Unless 
  890. they are declared 'volatile')
  891.  
  892. >I have a horrible macro called TAG(X) defined like this:
  893. >#define TAG(X) \
  894. >((!(heap[X]&1))?(heap[X]&3):((!(heap[X]&2))?(heap[X]&15):(heap[X]&63)))
  895. >
  896. >THINK C's debugger lets me place the expression TAG(X) in the "data"
  897. >window and see a value (like 1 or 63). I find this soooo useful.
  898. >Please consider adding something similar. 
  899.  
  900. This will not be possible with our current debugger/compiler 
  901. architecture. THINK C is one of the only environments I've ever seen 
  902. which does this; it is a side-effect of the way the debugger works, which 
  903. is to call the compiler to evaluate the expression.
  904.  
  905. We will probably support some form of expression evaluation in the 
  906. debugger eventually (post-DR3) but it will probably not include macro 
  907. expansion.
  908.  
  909. -- John McEnerney, Metrowerks PowerPC Product Architect
  910.  
  911.  
  912. +++++++++++++++++++++++++++
  913.  
  914. >From tchan@irus.rri.uwo.ca (Thomas KC Chan)
  915. Date: 24 Mar 1994 16:46:07 GMT
  916. Organization: Imaging Labs, Robarts Research Institute, London
  917.  
  918.  
  919. Michael Levy, thanks you for sharing your list with us.
  920.  
  921.  
  922. In article <Cn5D2z.94F@world.std.com> johnmce@world.std.com (John McEnerney) writes:
  923. >>int t1,t2;
  924. >>....
  925. >>t1 = 1000;
  926. >>t2 = 2000;
  927. >>...
  928. >>the debugger showed the same values for t1 and t2, and
  929. >>changed them simultaneously!
  930. >
  931. >This is probably -not- a bug in the debugger. If the compiler can 
  932. >determine that t1 and t2 will never be live simultaneously, it is free to 
  933. >place them in the same register or memory location. In fact, it is free 
  934. >to delete the assignments altogether if t1 and t2 are never used. (Unless 
  935. >they are declared 'volatile')
  936.  
  937. As a high-level language programmer, I don't think I have to worry 
  938. about which register is assigned to which variable.
  939.  
  940. If this happens only when certain optimization option is on, then it is not
  941. a bug; otherwise it definitely is a bug!  Can Michael verify this?
  942.  
  943.  
  944. >>I have a horrible macro called TAG(X) defined like this:
  945. >>#define TAG(X) \
  946. >>((!(heap[X]&1))?(heap[X]&3):((!(heap[X]&2))?(heap[X]&15):(heap[X]&63)))
  947. >>
  948. >>THINK C's debugger lets me place the expression TAG(X) in the "data"
  949. >>window and see a value (like 1 or 63). I find this soooo useful.
  950. >>Please consider adding something similar. 
  951. >
  952. >This will not be possible with our current debugger/compiler 
  953. >architecture. THINK C is one of the only environments I've ever seen 
  954. >which does this; it is a side-effect of the way the debugger works, which 
  955. >is to call the compiler to evaluate the expression.
  956.  
  957. How about unix's dbx & debuggers on VMS ... ?  This feature is definitely
  958. needed.  As a matter of facts, CW debugger is the only one I used so far
  959. that lack of this feature.
  960.  
  961. I also want the capability of hidding some of the variables
  962. (local & global) that I am not interested in.  Currently I have to
  963. scroll the window ups & downs just to see the variables I have
  964. doubts on...  (Have I overlooked that such feature is already
  965. implemented in CW debugger?!!)
  966.  
  967.  
  968. As for my second question, I only want to overwrite the same line on
  969. the screen by using a "<cr>" character instead of a "<nl>" in the
  970. ANSI "printf" function.  Any special character I could use to 
  971. send to CW's SIOUX to simulate this behavior?!
  972.  
  973. (Any way to re-position a SIOUX window besides manually draging it?
  974. Any DOC on SIOUX besides the on-line User Manuals that comes with 
  975. the CD-ROM?)
  976.  
  977.  
  978. I always want to ask this: Is "support@metrowerks.ca" the
  979. e-mail address for "support" from Metrowerks.  (It was printed on
  980. the little booklet that comes with the CW CD-ROM.)  I have sent my 
  981. queries there for a couple/several weeks but never got any
  982. replies ??!!
  983.  
  984.  
  985.  
  986. ---------------------------
  987.  
  988. >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
  989. Subject: Quickdraw GX Beta 3 fun
  990. Date: 23 Mar 94 12:00:23 +1300
  991. Organization: University of Waikato, Hamilton, New Zealand
  992.  
  993. Just for fun, I tried duplicating the example on page 207 of the PostScript
  994. Red Book, 2nd Ed.
  995.  
  996. For those without the book, the design is a large letter A against a rectangular
  997. background. Both the letter and the rectangle are filled with a pattern of
  998. stars, alternately black and grey.
  999.  
  1000. The first snag I hit is that QuickDraw GX doesn't allow multicoloured fill
  1001. patterns--not unless you use a bitmap for the pattern shape, I guess. So all
  1002. my stars are one colour for now.
  1003.  
  1004. The second problem I hit was that the fill for the letter would not draw
  1005. properly: stars would appear well outside the character outline. This bug
  1006. is still present in beta 3, but I can get around it by changing the shape
  1007. type from text to a path. The same thing would happen for the rectangle
  1008. before, but this works properly in beta 3.
  1009.  
  1010. The next problem was that the fills for the rectangle and the letter would
  1011. not match up--the positions of the stars were different. This is also fixed
  1012. in beta 3.
  1013.  
  1014. All in all, the betas are getting better and better. I hope release isn't
  1015. too far off now...
  1016.  
  1017. Lawrence D'Oliveiro                       fone: +64-7-856-2889
  1018. Info & Tech Services Division              fax: +64-7-838-4066
  1019. University of Waikato            electric mail: ldo@waikato.ac.nz
  1020. Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
  1021.  
  1022. +++++++++++++++++++++++++++
  1023.  
  1024. >From dowdy@apple.com (Tom Dowdy)
  1025. Date: Wed, 23 Mar 1994 00:46:58 GMT
  1026. Organization: Apple Computer, Inc.
  1027.  
  1028. In article <1994Mar23.120024.26760@waikato.ac.nz>, ldo@waikato.ac.nz
  1029. (Lawrence D'Oliveiro, Waikato University) wrote:
  1030.  
  1031. > Just for fun, I tried duplicating the example on page 207 of the PostScript
  1032. > Red Book, 2nd Ed.
  1033. > For those without the book, the design is a large letter A against a rectangular
  1034. > background. Both the letter and the rectangle are filled with a pattern of
  1035. > stars, alternately black and grey.
  1036. > The first snag I hit is that QuickDraw GX doesn't allow multicoloured fill
  1037. > patterns--not unless you use a bitmap for the pattern shape, I guess. So all
  1038. > my stars are one colour for now.
  1039.  
  1040. Ah!
  1041.  
  1042. You can make *two* shapes, each filled with a different pattern/color.
  1043. I haven't seen the picture in a while, but I assume that it's just
  1044. one phase is gray and another black.  Since only the pattern
  1045. areas of the filled shape are blitted, you can place them on
  1046. top of one another to get the alternating behavior you mention.
  1047.  
  1048. -- 
  1049.  Tom Dowdy                  Internet: dowdy@apple.COM
  1050.  Apple Computer MS:302-3KS  UUCP: {sun,voder,amdahl,decwrl}!apple!dowdy
  1051.  1 Infinite Loop            AppleLink: DOWDY1
  1052.  Cupertino, CA 95014       
  1053.  "The 'Ooh-Ah' Bird is so called because it lays square eggs."
  1054.  
  1055. ---------------------------
  1056.  
  1057. >From jarezina@magnus.acs.ohio-state.edu (Jasna M. Arezina-Wilson)
  1058. Subject: Spoofing a serial port
  1059. Date: 22 Mar 1994 20:54:55 GMT
  1060. Organization: Ohio State University
  1061.  
  1062. I have a need to write an app/extension/cdev that will allow me to either
  1063. intercept a port speed call and/or modify said call (the reason is that I
  1064. have an older software package that drives the port at 19200, but my lab's
  1065. scanner interface is limited to 9600, and the software doesn't let me
  1066. change the port speed). Before I start on this nasty little project, does
  1067. anyone have any tips/clues/warnings?
  1068.  
  1069. - -------------------------------------------------------
  1070. #include <standard.disclaimer.h>
  1071. /* "My words are my own, and nobody paid me to say them." */
  1072. void void(void);   /* void where voided */
  1073.  
  1074. +++++++++++++++++++++++++++
  1075.  
  1076. >From Frank Price <wprice@jarthur.claremont.edu>
  1077. Date: 22 Mar 1994 22:40:47 GMT
  1078. Organization: Pomona College
  1079.  
  1080. In article <jarezina-220394155129@slip1-36.acs.ohio-state.edu> Jasna M.
  1081. Arezina-Wilson, jarezina@magnus.acs.ohio-state.edu writes:
  1082. >I have a need to write an app/extension/cdev that will allow me to either
  1083. >intercept a port speed call and/or modify said call (the reason is that I
  1084. >have an older software package that drives the port at 19200, but my lab's
  1085. >scanner interface is limited to 9600, and the software doesn't let me
  1086. >change the port speed). Before I start on this nasty little project, does
  1087. >anyone have any tips/clues/warnings?
  1088.  
  1089. A MUCH better idea would be to modify the subject program's code directly. 
  1090. Making a patch on PBControl would be unreliable depending on how they
  1091. decided to set the baud rate.  There are two ways to set the baud rate. 
  1092. One is a PBControl with csCode of 13 (this is from memory so don't quote
  1093. me).  The other is the standard SerReset call which the Apple glue should
  1094. translate into a different PBControl call (see Serial Driver chapter of
  1095. IM).  Basically, use Macsbug (TMON would be a lot easier here) to trap on
  1096. all PBControl calls in the app.  Look at the csCode.  When you find the
  1097. place in the code that the appropriate call is occurring, use the ResEdit
  1098. CODE disassembler or similar device to edit the hex instructions directly
  1099. to modify the baud rate requested into what you really want.  This solution
  1100. will solve your problem permanently and reliably, and will not introduce a
  1101. whole slew of potential problems caused by trap patches.
  1102.  
  1103. -Frank
  1104. _______________________________________________________________________
  1105. | Frank Price   |  wprice@jarthur.claremont.edu                        |
  1106. |_______________|______________________________________________________|
  1107.  
  1108. +++++++++++++++++++++++++++
  1109.  
  1110. >From jarezina@magnus.acs.ohio-state.edu (Jasna M. Arezina-Wilson)
  1111. Date: 23 Mar 1994 15:44:41 GMT
  1112. Organization: Ohio State University
  1113.  
  1114. In article <2mns5f$jje@jaws.cs.hmc.edu>, Frank Price
  1115. <wprice@jarthur.claremont.edu> wrote:
  1116.  
  1117. > [Idea on using MacsBug to hack serial speed]
  1118.  
  1119. This is pretty much what I did. The problem I had in not doing this in the
  1120. first place is that I had no way to get MacsBug to run (no int button on
  1121. the SE here), so I had to track down the F-Key to get into MacsBug. Plus,
  1122. adding to the fact that I have never used MacsBug before (other than
  1123. finding where my program crashed), it was real fun. I still wasn't able to
  1124. change the baud-rate directly - I had to patch the code and check the
  1125. control call, but at least it works!
  1126.  
  1127. (PS: I still think writing a program to spoof the baud rate would be
  1128. interesting)
  1129.  
  1130.  
  1131.  
  1132. - -------------------------------------------------------
  1133. #include <standard.disclaimer.h>
  1134. /* "My words are my own, and nobody paid me to say them." */
  1135. void void(void);   /* void where voided */
  1136.  
  1137. ---------------------------
  1138.  
  1139. >From Dan Crevier <crevier@husc.harvard.edu>
  1140. Subject: Using Think Pascal Library in SC++
  1141. Date: 22 Mar 94 05:18:13 GMT
  1142. Organization: Harvard University
  1143.  
  1144.  
  1145.     Hi, I'm trying to use the WASTE TextEdit engine with SC++.  WASTE 
  1146. comes with WASTE.lib, a Think Pascal library.  I used oConv from Think C 
  1147. 5.0 (I couldn't add it to my project to use the .o converter...).  That 
  1148. gave me a .pi file I could add to the project, and when I tried to link, 
  1149. I got a message that WESetInfo, _LMUL, and _LDIV weren't defined.  I 
  1150. assume that the are some long multiplication and division routines.  Can 
  1151. I write short routines to implement these?  I have MWC, and MPW, but not 
  1152. Think Pascal.  
  1153.     As for WESetInfo, I used DumpObj from MPW (I'd never used it 
  1154. before, I'm not a MPW person), and it showed a list of routines at the 
  1155. top with EP= in front of them, and the routine name in all caps 
  1156. (including WESETINFO).  What does this mean?
  1157.  
  1158.     Any help would be appreciated.
  1159.  
  1160. Thanks.
  1161.  
  1162. dan
  1163.  
  1164.  
  1165. +++++++++++++++++++++++++++
  1166.  
  1167. >From ingemar@lysator.liu.se (Ingemar Ragnemalm)
  1168. Date: Thu, 24 Mar 1994 10:49:25 GMT
  1169. Organization: (none)
  1170.  
  1171. Dan Crevier <crevier@husc.harvard.edu> writes:
  1172.  
  1173. >    Hi, I'm trying to use the WASTE TextEdit engine with SC++.  WASTE 
  1174. >comes with WASTE.lib, a Think Pascal library.  I used oConv from Think C 
  1175. >5.0 (I couldn't add it to my project to use the .o converter...).  That 
  1176. >gave me a .pi file I could add to the project, and when I tried to link, 
  1177. >I got a message that WESetInfo, _LMUL, and _LDIV weren't defined.  I 
  1178. >assume that the are some long multiplication and division routines.  Can 
  1179. >I write short routines to implement these?  I have MWC, and MPW, but not 
  1180. >Think Pascal.  
  1181.  
  1182. This is exactly the problem I wrote about in my recent post (about how to
  1183. make SAT work under Think C v6).
  1184.  
  1185. 1) You must include uRuntime.lib. Convert it to a C library and include it.
  1186. Using Think C 5, this was all you had to do. (You may have to fiddle with
  1187. the .v file a bit too.)
  1188.  
  1189. 2) Under Think C 6 (or C++), there's a bug in the linker (?) that makes it
  1190. really confused with uRuntime.lib. You must open it with Think C 5 and REMOVE
  1191. the segment named TOOLBOX. Ugly, isn't it?
  1192.  
  1193.  
  1194.  
  1195. --
  1196. - -
  1197. Ingemar Ragnemalm, PhD
  1198. Image processing, Mac shareware games
  1199. E-mail address: ingemar@isy.liu.se or ingemar@lysator.liu.se
  1200.  
  1201. ---------------------------
  1202.  
  1203. >From alex@metcalf.demon.co.uk (Alex Metcalf)
  1204. Subject: rowBytes for the screen too big?
  1205. Date: Sat, 19 Mar 1994 00:52:44 GMT
  1206. Organization: Demon Internet
  1207.  
  1208.  
  1209.    Hey there!
  1210.  
  1211.    After hacking around with my custom CopyBits routine (which works
  1212. nicely, BTW), I checked what the rowBytes was for the screen's PixMap. My
  1213. screen's only 640 pixels wide (in 8-bit, so one pixel per byte), but the
  1214. rowBytes is 1024. What gives? Is this something to do with making the
  1215. transfer faster in/out of video RAM?
  1216.  
  1217.       Hmm...
  1218.  
  1219.  
  1220.    Alex
  1221.    alex@metcalf.demon.co.uk
  1222.  
  1223. +++++++++++++++++++++++++++
  1224.  
  1225. >From mssmith@afterlife.ncsc.mil (M. Scott Smith)
  1226. Date: Sat, 19 Mar 1994 04:35:11 GMT
  1227. Organization: The Great Beyond
  1228.  
  1229. In article <alex-190394005149@metcalf.demon.co.uk> alex@metcalf.demon.co.uk (Alex Metcalf) writes:
  1230. >
  1231. >   Hey there!
  1232. >
  1233. >   After hacking around with my custom CopyBits routine (which works
  1234. >nicely, BTW), I checked what the rowBytes was for the screen's PixMap. My
  1235. >screen's only 640 pixels wide (in 8-bit, so one pixel per byte), but the
  1236. >rowBytes is 1024. What gives? Is this something to do with making the
  1237. >transfer faster in/out of video RAM?
  1238. >
  1239. >      Hmm...
  1240. >   Alex
  1241.  
  1242. Alex,
  1243.  
  1244.    If your rowBytes is sincerely 1024, then take your Mac to an Apple
  1245. service center immediately.  It must be quarantined before you begin to
  1246. cause others' Macs to have obscure video symptoms.
  1247.  
  1248.    But seriously..  You've discovered a truth about how video works on
  1249. Macs, and some pretty quantitative evidence why it's not safe to assume
  1250. that jumping ahead 640 bytes puts you on the next line (particularly if
  1251. you're fooling around with direct-screen addressing, as I do).
  1252.  
  1253.    Part of the reasoning behind this (and this is true of all video cards,
  1254. Mac and non-Mac) is that you can't buy a, say, 3.7 byte RAM chip.  RAM
  1255. chips only come in certain sizes, so it's not really possible to have
  1256. _exactly_ the right amount of RAM for the screen dimensions and depth.
  1257. Since it probably wouldn't be a good idea to have _less_, most video cards
  1258. have _more_ -- and "jump up" to the most convenient (cheap, etc.) amount.
  1259.  
  1260.    Keep in mind that most video cards can drive monitors of varying
  1261. resolutions, and depths.  If you switch your monitor to black and white
  1262. mode, you don't even need 640 bytes per scanline.  (More like 80.)  Jump
  1263. it up to 24-bit mode, and you need quite a bit more.  There's _always_
  1264. going to be wasted space, even if you're at the best monitor configuration
  1265. your video hardware can support.  (Step beyond that, and your video
  1266. hardware won't support it -- which is a good reason why you can often
  1267. get 24-bit color on 13" monitors with some cards, but not on 21"
  1268. monitors.)
  1269.  
  1270.    Now, you're talking about the screen's PixMap.  In my own PixMap's I
  1271. "align" the data to fit nice boundaries, and there's handy formulas for
  1272. doing this.  In that case it does benefit things like CopyBits.  The
  1273. strategy is that you have a width and height of "usable" space in a PixMap
  1274. (what you intend to actually be there), and rowBytes (and colBytes)
  1275. might not necessarily jive with width and height.  So you subtract
  1276. rowBytes from width to know how to get to the next line in a PixMap.  But
  1277. there's other reasons, as I listed, for the screen's PixMap to be super-
  1278. aligned.
  1279.  
  1280.    Now, just think!  You've found a lot of extra RAM that you can use if
  1281. you need!  Let's see, 1024-640 = 384 * 480 = 180k of free RAM!  (Pardon
  1282. any math errors, it's late.)  And imagine what's in store with video
  1283. cards that are perfectly happy driving 21" monitors in 24-bit color but
  1284. are only hooked up to 12" black and white monitors..
  1285.  
  1286.    Of course I'm sort of kidding.  But that extra RAM has been put to
  1287. good use in the past; as I recall, someone wrote a program called
  1288. MaxAppleSomethingOrOther that "enlarged" the dimensions of the 13" monitor
  1289. when used with the 8/8-24 video card.  (It essentially got rid of the black
  1290. borders around the 13" screen.)  It didn't work with my 8-24GC, darn it,
  1291. so I never got to try it, but I saw it and it was neat.
  1292.  
  1293.    In any case, it can be baffling to see inflated rowBytes but that's how
  1294. it is; just be sure to make no relations between width of screen and number
  1295. of bytes dedicated to each line by the video card..
  1296.  
  1297.    Hope that made sense!
  1298.  
  1299. Have fun,
  1300.  
  1301. Scott
  1302.  
  1303. - -
  1304. M. Scott Smith   (mssmith@afterlife.ncsc.mil || umsmith@mcs.drexel.edu)
  1305.  
  1306.   Mac developer. Student. Ski bum.  Not responsible for the national debt.
  1307.  
  1308.  
  1309. +++++++++++++++++++++++++++
  1310.  
  1311. >From phixus@netcom.com (Chris DeSalvo)
  1312. Date: Mon, 21 Mar 1994 04:48:51 GMT
  1313. Organization: NETCOM On-line Communication Services (408 241-9760 guest)
  1314.  
  1315. Alex Metcalf (alex@metcalf.demon.co.uk) wrote:
  1316.  
  1317. :    Hey there!
  1318.  
  1319. :    After hacking around with my custom CopyBits routine (which works
  1320. : nicely, BTW), I checked what the rowBytes was for the screen's PixMap. My
  1321. : screen's only 640 pixels wide (in 8-bit, so one pixel per byte), but the
  1322. : rowBytes is 1024. What gives? Is this something to do with making the
  1323. : transfer faster in/out of video RAM?
  1324.  
  1325.  
  1326. Always do a & 0x07FF on a rowBytes field before using it.
  1327.  
  1328. L8R
  1329. Chris
  1330. -- 
  1331. +-----------------------------------------------------------------+
  1332. | phixus@netcom.com           |   Macintosh:  Changing the world, |
  1333. | Chris De Salvo              |        one person at a time!      |
  1334. | Professional Mac Geek       |    -----------------------------  |
  1335. | MacPlay, Irvine, CA         |      (I wish they'd hurry up!)    |
  1336. +-----------------------------------------------------------------+
  1337.  
  1338. Any opinions expressed, or implied, are my own!  They should not be
  1339. considered representative of the opinions or policies of my employer,
  1340. MacPlay, a division of Interplay Productions, Inc.
  1341.  
  1342. +++++++++++++++++++++++++++
  1343.  
  1344. >From phixus@netcom.com (Chris DeSalvo)
  1345. Date: Tue, 22 Mar 1994 07:45:08 GMT
  1346. Organization: NETCOM On-line Communication Services (408 241-9760 guest)
  1347.  
  1348. Chris DeSalvo (phixus@netcom.com) wrote:
  1349. : Alex Metcalf (alex@metcalf.demon.co.uk) wrote:
  1350. : :    Hey there!
  1351. : :    After hacking around with my custom CopyBits routine (which works
  1352. : : nicely, BTW), I checked what the rowBytes was for the screen's PixMap. My
  1353. : : screen's only 640 pixels wide (in 8-bit, so one pixel per byte), but the
  1354. : : rowBytes is 1024. What gives? Is this something to do with making the
  1355. : : transfer faster in/out of video RAM?
  1356.  
  1357.  
  1358. : Always do a & 0x07FF on a rowBytes field before using it.
  1359.  
  1360. Mistake already realised.  Please, no flames.  I was thinking GWorlds,
  1361. not monitors.
  1362.  
  1363. Yes, a monitor's rowBytes might very well be 1024 because 1K block
  1364. transfers probably go a heck of a lot faster than 640K transfers.
  1365.  
  1366.  
  1367. Chris
  1368.  
  1369. -- 
  1370. +-----------------------------------------------------------------+
  1371. | phixus@netcom.com           |   Macintosh:  Changing the world, |
  1372. | Chris De Salvo              |        one person at a time!      |
  1373. | Professional Mac Geek       |    -----------------------------  |
  1374. | MacPlay, Irvine, CA         |      (I wish they'd hurry up!)    |
  1375. +-----------------------------------------------------------------+
  1376.  
  1377. Any opinions expressed, or implied, are my own!  They should not be
  1378. considered representative of the opinions or policies of my employer,
  1379. MacPlay, a division of Interplay Productions, Inc.
  1380.  
  1381. +++++++++++++++++++++++++++
  1382.  
  1383. >From paul@taniwha.com (Paul Campbell)
  1384. Date: 24 Mar 1994 06:37:09 GMT
  1385. Organization: Taniwha Systems Design
  1386.  
  1387. In article <phixusCn001F.n4u@netcom.com>
  1388. phixus@netcom.com (Chris DeSalvo) writes:
  1389. > Alex Metcalf (alex@metcalf.demon.co.uk) wrote:
  1390. > :    After hacking around with my custom CopyBits routine (which works
  1391. > : nicely, BTW), I checked what the rowBytes was for the screen's PixMap. My
  1392. > : screen's only 640 pixels wide (in 8-bit, so one pixel per byte), but the
  1393. > : rowBytes is 1024. What gives? Is this something to do with making the
  1394. > : transfer faster in/out of video RAM?
  1395.  
  1396. nah ... it's just easier for the hardware guys - esp. if the same 
  1397. hardware has to do 1024x768 - chances are you weren't going to use 
  1398. that extra memory anyway
  1399.  
  1400. > Always do a & 0x07FF on a rowBytes field before using it.
  1401.  
  1402. NO!! ... always do a & 0x7FFF before using it [and DON'T do as older
  1403. IMs
  1404. suggest do an & 0x3FFF - there are now cards out there with genuine 
  1405. rowbytes equal to 0x4000 (or greater) - if you bypass quickdraw 
  1406. and write directly to the screen BEWARE!)
  1407.  
  1408.     Paul
  1409.  
  1410. ______________________________________________________________________
  1411. Paul Campbell                                         paul@taniwha.com
  1412. "Xenon? It's a rare gas ...."
  1413.  
  1414. ---------------------------
  1415.  
  1416. End of C.S.M.P. Digest
  1417. **********************
  1418.  
  1419.  
  1420.  
  1421.